dos: add directory-relative file functions#566
Conversation
With a little shuffling of shared functions
This is really just fiddling around the edges. I don't love that heap allocation there, but eh, its a rarely-hit codepath anyway. At least now its tidier and out of the way.
These all just wrap getpacketinfo in a nice easy dumb way.
|
I wanted to see this land, so I rebased the branch onto current master and verified it. A rebased copy is at The branch turned out to be in good shape:
Verified on a darwin/aarch64 hosted build: dos.library compiles clean and the system boots without regression. Since On the two open considerations from the description: the 12 new LVOs are appended at the tail of |
|
Worth flagging a tradeoff before anyone reimplements this as a support library: the current code is deliberately race-free. LockRelative/OpenRelative talk to the filesystem handler directly with the base lock (fl_Task packets + the internal ResolveSoftlink), so there is no intermediate path assembly and no TOCTOU window on a retargeted symlink, which was the stated motivation. A support library limited to the public dos API cannot preserve that: relative-to-lock there means either CurrentDir(lock)+Open (mutates the process CWD, not reentrant) or NameFromLock+AddPart+Open (reassembles a path, reintroducing the symlink race). Both give weaker semantics than the LVO version. So it seems like a design call: (a) a convenience wrapper in arossupport over the public API, accepting non-atomic relative ops, or (b) keep the race-free handler-level implementation but move it off the primary dos LVO table via a secondary base / internal-linked helper. Happy to do the legwork on whichever you would prefer -- which semantics do you want these to have? |
|
You're right, I had that backwards. The atomicity is in the handler's ACTION_LOCATE_OBJECT (the name is resolved against the parent lock in a single packet), and that is fully reachable from the public API: DoPkt to the lock's fl_Task, or GetDeviceProc for the device case, with the standard ACTION_* actions for the rest. The internal fs_LocateObject/dopacket3 wrappers robn used are just conveniences for code living inside dos, not a capability only dos has, so a supplementary shared library gets the same race-free behaviour with the official dos API left untouched. Agreed it shouldn't be bolted into dos. I'm happy to build that: a separate dosrelative.library exposing the relative set, each function doing GetDeviceProc / fl_Task then DoPkt(ACTION_LOCATE_OBJECT / MAKE_LINK / RENAME_OBJECT / ...) directly, i.e. robn's logic re-homed onto public DoPkt. The name is just a placeholder that says what it does; happy to use whatever you'd prefer. Sound like the right shape before I start? |
2 participants
This adds extended versions of all DOS functions that take a filename and interpret a relative name against the current working directory to take a directory lock and a filename, and then interpret a relative name against the given lock.
This lets an application avoid race conditions when operating on files outside the current working directory. The application has to assemble path strings to do this, and there's a possibility that one of the intermediate path components could be a link, and another process could retarget it.
This is analogous to the POSIX
*atcollection of functions (egopenat,linkat, etc). And indeed, that's part of why I want these: so I can cleanly implement the POSIX wrappers without out having to resort to (complex) path mangling (see https://github.com/robn/AROS/commits/posixc-openat for a work-in-progress implementation ofopenaton top of this).Open considerations:
*Relativeis a lot to type, but accurate.*Atmight be better. I don't particularly care; strong opinions welcome.